Feature/dynamic service key credentials - #1929

Add ServiceKeyCredentialResolver, which replaces
{ds/<resource>/service-keys.<key>.credentials.<field>} references in a
service key's credentials by reading the referenced (already created)
service key's credentials from the Cloud Controller and extracting the
addressed field. Missing fields fail loudly with a clear message.

Wire it in via a new idempotent ResolveServiceKeyCredentialReferencesStep,
inserted in create-service-key.bpmn between the operation-in-progress
check and createServiceKey, so a referenced resource's key (guaranteed to
be in an earlier, already-completed batch by processed-after) is read back
just before the consuming key is created.

ResolveServiceKeyCredentialReferencesStep now builds the
relationship->service-instance-name map from the deployment descriptor,
using each resource's service-name parameter (falling back to the
resource name). Previously it passed an empty map, so the credential
read-back used the resource name as the service instance name and failed
for resources whose service-name differs from their resource name.

The binding-resolution step runs inside the manageAppServiceBindingSubProcess
Flowable sub-process, which does not inherit COMPLETE_DEPLOYMENT_DESCRIPTOR.
Build the relationship->service-instance-name map from Variables.SERVICES_TO_BIND
(each CloudServiceInstanceExtended carries getResourceName() and getName()),
which is passed into the sub-process and already precomputes the resolved CF
service instance names. The referenced resource must be among the module's
required dependencies so it appears in SERVICES_TO_BIND.